home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1993
/
Internet Info CD-ROM (Walnut Creek) (1993).iso
/
inet
/
internet-drafts
/
draft-ietf-pem-mime-03.txt
< prev
next >
Wrap
Text File
|
1993-10-26
|
42KB
|
1,235 lines
Network Working Group Steve Crocker
Internet Draft Ned Freed
<draft-ietf-pem-mime-03.txt> Jim Galvin
Sandy Murphy
Marshall Rose
MIME-PEM Interaction
Oct 15, 1993
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are valid for a maximum of six months and may
be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet Drafts as reference
material or to cite them other than as a "work in progress".
2. Abstract
This memo defines a framework for interaction between MIME and
PEM services. MIME, an acronym for "Multipurpose Internet
Mail Extensions", defines the format of the contents of
Internet mail messages and provides for multi-part textual and
non-textual message bodies. PEM, an acronym for "Privacy
Enhanced Mail", provides message encryption and message
authentication/integrity services for Internet mail messages.
draft MIME-PEM Interaction Oct 1993
3. Introduction
An Internet electronic mail message consists of two parts: the
headers and the body. The headers form a collection of
field/value pairs structured according to RFC 822 [1], whilst
the body, if structured, is defined according to MIME [2].
MIME does not provide encryption or authentication/integrity
services.
PEM [3-6] allows encryption and authentication/integrity
enhancements to be applied to the contents of electronic mail
messages but does not provide message structuring or type
labelling facilities.
This memo defines a framework whereby the services provided by
MIME and PEM are used in a complementary fashion. The
resulting combined service provides encryption and
authentication/integrity services for single-part and multi-
part textual and non-textual messages. We refer to the
authentication/integrity service as a signature.
The services of encryption and signature are separated. This
differs from the service provided by [3], in that the
encryption privacy enhancement in [3] also computes a
signature of the message. To take full advantage of the
functionality provided by MIME, canonicalization and transfer
encoding operations are removed from the privacy enhancement
and left to the MIME agent. The content domain header,
defined in [3], is not included, as its functionality is
subsumed by MIME. Transmission of certificate and certificate
revocation lists is separated from the privacy enhancement.
The message types no longer need be mentioned in the headers,
as the information they impart is contained in the content
types. The requests and responses of [6] are provided for in
new content types.
This represents a departure in mechanism, although not in
effect, from the procedures identified in [3].
Expires Apr, 1994 [Page 2]
draft MIME-PEM Interaction Oct 1993
MIME-PEM interaction is provided for by defining six new MIME
content types: application/pem-keys, application/pem-
signature, application/pem-encrypted, application/quoted-mime-
entity, application/pem-request and application/certdata. The
MIME-PEM interaction also uses another new MIME type,
multipart/headerset, proposed by David Crocker. The
relationship between MIME and PEM is described in terms of two
functions, message composition and message delivery.
The new content types have two different purposes. The first
four types (application/pem-keys, application/pem-signature,
application/pem-encrypted and application/quoted-mime-entity)
are used to transmit and receive privacy enhanced messages and
are always encapsulated in a multipart/headerset body part.
The last two types (application/pem-request and application/
certdata) are used to transmit requests for certificate
operations (retrieval, certification, revocation lists
retrieval, etc.) and the responses to those requests. These
two content types are independent body parts, not required to
be encapsulated in any other body part. The two groups of
content types are discussed in the two sections following.
4. Definition of new enhancement Content Types
4.1. Multipart/headerset Content Type Definition
(1) MIME type name: multipart
(2) MIME subtype name: headerset
(3) Required parameters: boundary
(4) Optional parameters: none
(5) Encoding considerations: Either 7bit, 8bit, or binary
encoding may be used, depending on the nested part
encodings and transport limitations.
(6) Security Considerations: see [3]
Expires Apr, 1994 [Page 3]
draft MIME-PEM Interaction Oct 1993
The headerset subtype of multipart always contains at least
two body parts, where the first body part gives instructions
in some way for the processing of all the body parts. In this
use of the headerset subtype, there are always two body parts.
The first part describes the privacy enhancement which was
applied to the second body part. The first part's content type
is application/pem-signature or application/pem-keys.
The second body part contains a body part which contains the
privacy-enhanced content. The second part's content type is
either application/pem-encrypted, if the requested privacy
enhancement is encryption, or application/quoted-mime-entity,
if the requested privacy enhancement is signature.
The syntax and semantics of the boundary parameter is defined
in [2].
4.2. Application/pem-keys Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem-keys
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
The canonical form of this content type corresponds to the
following production for <pemkeys>, which differs from the
<pemhdr> in [3] in that neither the <crlhdr> nor the fields
conveying certificates or related exclusively to signature are
a part of the production. (The certificate fields appear in
the application/certdata content type, see Section 5.2). The
<contentdomain> field is also eliminated. The <proctype>
field is replaced by the <version> field, as the message types
included in <proctype> are imparted by the content type name
of the body part. The productions <dekinfo>, <origid-asymm>,
Expires Apr, 1994 [Page 4]
draft MIME-PEM Interaction Oct 1993
<origid-symm>, <recipflds> and <keyinfo> are as defined in
section 9 of [3].
<pemkeys> ::= <version>
<dekinfo>
(1*(<origkeyflds> *<recipflds>)) ; symmetric case
/((1*<origkeyflds>) *(<recipflds>)) ; asymmetric case
<version> ::= "Version" ":" "5" CRLF
<origkeyflds> ::= <origid-asymm> [<keyinfo>] ;asymmetric
/ <origid-symm> [<keyinfo>] ;symmetric
This content type must be used as the first part of a
multipart/headerset content type. It may not be used in any
other context.
4.3. Application/pem-signature Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem-signature
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
The canonical form of this content type corresponds to the
following production for <pemsig>, which differs from the
<pemhdr> in [3] in that neither the <crlhdr> nor the fields
conveying certificates or related exclusively to encryption
are a part of the production. (The certificate fields appear
in the application/certdata content type, see Section 5.2).
The <contentdomain> field is also eliminated. The <proctype>
field is replaced by the <version> field, as the message types
included in <proctype> are imparted by the content type name
of the body part. The productions <keyinfo>, <micinfo>,
Expires Apr, 1994 [Page 5]
draft MIME-PEM Interaction Oct 1993
<recipflds>, <origid-asymm> and <origid-symm> are as defined
in section 9 of [3].
<pemsig> ::= <version>
(1*(<origsigflds> *<recipflds>)) ; symmetric case
/((1*<origsigflds>) *(<recipflds>)) ; asymmetric case
<version> ::= "Version" ":" "5" CRLF
<origsigflds> ::= <origid-asymm> [<keyinfo>]
<micinfo> ;asymmetric
/ <origid-symm> [<keyinfo>] ;symmetric
This content type must be used as the first part of a
multipart/headerset content type. It may not be used in any
other context.
4.4. Application/pem-encrypted Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem-encrypted
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: The encryption will produce
binary data and may need to be encoded for transport.
Any transport-compatible encoding capable of
accommodating binary data may be used. A base64
encoding will be sufficient for all transport systems.
(6) Security Considerations: see [3]
The content of the application/pem-encrypted is an encrypted
valid MIME object. Because it is encrypted, the canonical
form of this content type is any arbitrary data.
This content type must be used as the second part of a
multipart/headerset content type. It may not be used in any
Expires Jan, 1994 [Page 6]
draft MIME-PEM Interaction Jul 1993
other context.
4.5. Application/quoted-mime-entity Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: quoted-mime-entity
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: If the quoted
mime body part has a quoted printable, 7bit, or base64
transfer encoding indicated, the transfer encoding
of this body part should be 7bit to avoid nested
encodings. Otherwise, any transport-compatible
encoding capable of accommodating the content type of
the quoted mime body part may be used.
(6) Security Considerations: see [3]
The application/quoted-mime-entity content is constrained to
be a valid MIME object. The content of that body part must be
in the canonical form for its content type.
This content type must be used as the second part of a
multipart/headerset content type. It may be used in any
other context, as well.
The application/quoted-mime-entity content type may on first
inspection appear to be superfluous since the content it
contains is itself constrained to be a valid MIME object.
However, the use of application/quoted-mime-entity serves a
vital function: it protects the inner MIME object from any
changes that might be performed by messaging gateways. Such
changes frequently disrupt header and boundary information,
which in turn would lead to integrity check failures.
Expires Apr, 1994 [Page 7]
draft MIME-PEM Interaction Oct 1993
The use of application/quoted-mime-entity ensures that if a
gateway is compelled to make encoding changes it will do so on
the application/quoted-mime-entity object as a whole. Such
encoding changes, if done properly, will leave the
application/quoted-mime-entity content entirely intact.
The application/quoted-mime-entity type may be generally
useful outside PEM, as well. We intend for this to be a type
that could be used anywhere in a MIME object and not
restricted to PEM.
5. Definition of new certificate Content Types
5.1. Application/pem-request Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem-request
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
The canonical form of this content type corresponds to the
following production.
<request> ::= <version>
<version> ::= "Version" ":" "5" CRLF
(<subject> / <issuer> / <certification>)
<subject> ::= "Subject" ":" <asymmid> CRLF
<issuer> ::= "Issuer" ":" <asymmid> CRLF
<certification> ::= "Certification" ":" <encbin> CRLF
The purpose of this body part is to transmit a request. The
request can be "Certification", which requests certification
of a self-signed certificate, or "Subject", which requests the
Expires Apr, 1994 [Page 8]
draft MIME-PEM Interaction Oct 1993
certificate chain corresponding to a subject identified by a
distinguished name, or "Issuer", which requests the revocation
list chain issued by an issuer identified by a distinguished
name. The "Subject" and "Issuer" fields each contain a value
of type Name, encoded according to the Basic Encoding Rules,
then in ASCII, as for the "Originator-ID-Asymmetric" field of
[3].
In each case, the response can be transmitted in an
application/certdata content type.
This type is intended to provide for the requests described
in [6]. The key certification request and CRL-retrieval
request are provided for directly. The CRL-storage request
is provided for by transmitting the CRL's to be stored in an
application/certdata content type.
5.2. Application/certdata Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: certdata
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
The canonical form of this content type corresponds to the
following production built on top of the definitions in
section 9 of [3].
<certdata> ::= <certchain> / <crlchain>
<certchain> ::= <version> (<cert> *([<crl>]<cert>))
<crlchain> ::= <version> 1*(<crl>[<cert])
<cert> ::= "Certificate" ":" <encbin> CRLF
<version> ::= "Version" ":" "5" CRLF
Expires Apr, 1994 [Page 9]
draft MIME-PEM Interaction Oct 1993
This content type is used to transfer certificate or
certificate revocation list information. This information is
entirely independent of any particular enhanced message. (Note
that the converse is not true: the validity of an enhanced
message cannot be determined without the proper certificates
or current CRL information.) As such, the application/pem-
certdata content type is an independent body part. It is not
used in a multipart/headerset context containing PEM enhanced
messages.
The <certchain> production contains one certificate chain.
Each certificate chain starts with a certificate and continues
with the certificates of subsequent issuers. Each issuer
listed is presumed to have issued the preceding certificate.
For each issuer, a CRL may be supplied. A CRL in the chain
belongs to the immediately following issuer. Therefore, it
potentially contains the immediately preceding certificate.
The <crlchain> production contains one certificate revocation
list chain. The CRLs in the chain begin with a requested CRL
and continue with the CRLs of subsequent issuers. The issuer
of each CRL is presumed to have issued a certificate for the
issuer of the preceding CRL. For each CRL, the issuer's
certificate may be supplied. A certificate in the chain must
belong to the issuer of the immediately preceding CRL.
The relationship between a certificate and an immediately
preceding CRL is the same in both cases. In a <certchain>
the crl's are optional. In a <crlchain>, the certificates
are optional.
6. Message Composition
When a user composes a message, it is the responsibility of
the user agent to construct a valid MIME message. In
particular, Content-Type: and Content-Transfer-Encoding:
headers should be used wherever they are appropriate. This
allows the receiving user agent to unambiguously interpret the
Expires Apr, 1994 [Page 10]
draft MIME-PEM Interaction Oct 1993
message body and process it accordingly.
Each block of content headers associated with either an RFC822
<message> or with a MIME <body-part> represents a logical
place where privacy enhancement can be requested. A privacy
enhancement request associated with a particular <message> or
<body-part> content is taken to apply to the entire content;
it is not possible to privacy-enhance only a portion of a body
part.
The mechanism used to communicate privacy enhancement requests
to the pre-submission processor described below is strictly a
local implementation issue. However, the interface between the
message composer and pre-submission processing MUST be
trustworthy, since the message composer relies on pre-
submission processing to either perform the requested privacy
enhancement operation or return an error. Regardless of the
mechanism chosen, great care should be taken to safeguard
against both the release of information that has not received
the requested type of privacy enhancement as well as tampering
with the enhancement request itself.
6.1. Pre-Submission Algorithm
The user agent first composes a MIME-compliant message and
then applies this algorithm:
(1) If the content at this (initially top) level has NOT been
selected for privacy enhancement, the user agent sees if
the content is either multipart or message. If so, it
then recursively applies this algorithm to the
encapsulated body parts; if not, it terminates processing
for this content.
(2) If the content at this level has been selected for
privacy enhancement, then the content, including its
headers, constitutes the object that receives privacy
enhancement. The headers at a minimum will include a
Content-Type header, either explicit or implicit. The
object will eventually be replaced with the multipart/
Expires Apr, 1994 [Page 11]
draft MIME-PEM Interaction Oct 1993
headerset content that is produced by the privacy
enhancement operation.
(3) The content of the object must be transformed from local
form to its MIME binary canonical form. Also, if the
requested privacy enhancement is signature, and if
Content-Transfer-Encoding: headers were present in the
headers of the object, the content encoding is reversed,
leaving only 7BIT, 8BIT, and BINARY as possible encodings
for all body parts. This is done so that any artifacts
introduced by encoding are removed and consistent
integrity checks will be generated.
(4) Once an object in binary canonical form has been produced
the selected privacy enhancement is performed. The
privacy enhancement produces two data streams: the
privacy enhanced object and a control stream comprised
of a set of headers as defined in the <pemsig> or
<pemkeys> productions.
(5) A new body part is then constructed, of content type
multipart/headerset. The body part contains two
body parts, whose content depends on the privacy
enhancement requested.
(a) If the requested privacy enhancement is encryption,
then the first body part within the multipart/
headerset is labelled with a content type of
application/pem-keys and contains the <pemkeys>
control stream produced by the privacy enhancement.
The second body part within the multipart/headerset
is labelled with a content type application/pem-
encrypted, and contains the privacy enhanced object
produced by the privacy enhancement. An appropriate
transfer encoding is also applied to the content and
a corresponding Content-Transfer-Encoding: header is
added to the application/pem-encrypted body part.
Base64 encoding is recommended in the case of
encryption privacy enhancement in order to be
backwards-compatible with the original PEM
conventions.
(b) If the requested privacy enhancement is signature,
then the first body part within the multipart/
headerset is labelled with a content type of
Expires Apr, 1994 [Page 12]
draft MIME-PEM Interaction Oct 1993
application/pem-signature and contains the <pemsig>
control stream produced by the privacy enhancement.
The second body part within the multipart/headerset
is labelled with a content type application/quoted-
mime-entity, and contains the privacy enhanced object
produced by the privacy enhancement. An appropriate
transfer encoding is also applied to the content and
a corresponding Content-Transfer-Encoding: header is
added to the application/quoted-mime-entity bodypart.
This multipart/headerset content replaces the original
object.
7. Post-Delivery Algorithm
When a user receives a message containing a multipart/
headerset content, the user agent may transform the content
back into its original form prior to privacy-enhancement.
This operation, the post-delivery algorithm, is performed by
reversing the steps performed during the pre-submission
algorithm.
When the original content is reconstituted into its MIME
binary canonical form, it may use octet values outside of the
US-ASCII repertoire and may contain body parts without line
breaks. If the user agent replaces the multipart/headerset
content with the original content, then it must select
appropriate Content-Transfer-Encodings for each body part and
add corresponding Content-Transfer-Encoding: headers.
Upon successful completion of the post-delivery algorithm for
each content, the type of privacy enhancement that was in
effect for that content must be communicated to the user. The
mechanism used to do this is a local implementation issue. As
with requests for privacy enhancement to the pre-submission
algorithm, the path between post-delivery processing and
actual display of the message must be a trusted one, lest a
message be presented that purports to have undergone some form
of privacy enhancement it did not in fact receive.
8. Examples
For example, suppose the following body part was selected for
Expires Apr, 1994 [Page 13]
draft MIME-PEM Interaction Oct 1993
privacy enhancement:
Content-Type: message/rfc822
To: ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Hi Ned. See how much nicer this works!
After applying pre-submission algorithm with a request that
signature privacy enhancement be applied to the body part, the
body part submitted for delivery would appear as:
Content-Type: multipart/headerset;
boundary="Privacy Boundary"
--Privacy Boundary
Content-Type: application/pem-signature
Version: 5
Originator-ID-Asymmetric: ...,09
MIC-Info: RSA-MD5,RSA,...
--Privacy Boundary
Content-Type: application/quoted-mime-entity
Content-Type: message/rfc822
To: ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Hi Ned. See how much nicer this works!
--Privacy Boundary--
After applying the post-delivery algorithm, the resulting
body part would once again appear as:
Expires Apr, 1994 [Page 14]
draft MIME-PEM Interaction Oct 1993
Content-Type: message/rfc822
To: ned@innosoft.com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Hi Ned. See how much nicer this works!
The body part need not be ascii text. For example, the
following audio body part could be privacy enhanced:
Content-Type: audio
Content-Transfer-Encoding: base64
JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH
GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD
kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj
producing the following body part:
Content-Type: multipart/headerset;
boundary="Privacy Boundary"
--Privacy Boundary
Content-Type: application/pem-signature
Version: 5
Originator-ID-Asymmetric: ...,09
MIC-Info: RSA-MD5,RSA,...
--Privacy Boundary
Content-Type: application/quoted-mime-entity
Content-Transfer-Encoding: 7bit
Content-Type: audio
Content-Transfer-Encoding: base64
JFJFGJGJJjfjgjgjghjJFGJGJKSKFJFG739475fgfhelkJHDJJGH
GJKjfdjjJHUjfjd27485jjJDGHj3j4jjHDJjfh5566kfjhJFDHDD
kwpritufnLKDJWYRIk6n47382oJDHFK4ie3y49JCBCMBVUei3hj
Expires Apr, 1994 [Page 15]
draft MIME-PEM Interaction Jul 1993
--Privacy Boundary--
The following privacy-enhanced message illustrates how an
enhanced body part can itself receive enhancement.
Date: Mon, 29 Mar 93 13:57:08 -0500
From: Greg Vaudreuil <gvaudre@CNRI.Reston.VA.US>
To: Marshall Rose <mrose@dbc.mtview.ca.us>
Subject: Forwarded integrity Message
MIME-Version: 1.0
Content-Type: multipart/headerset;
boundary="Privacy Boundary"
--Privacy Boundary
Content-Type: application/pem-signature
Version: 5
Originator-ID-Asymmetric: ...,09
MIC-Info: RSA-MD5,RSA,...
--Privacy Boundary
Content-Type: application/quoted-mime-entity
Content-Type: multipart/mixed;
boundary="Middle Boundary"
--Middle boundary
Content-Type: text/plain; charset=us-ascii
The enclosed message was integrity enhanced.
Greg V.
--Middle Boundary
Content-Type: multipart/headerset;
boundary="Forwarded Message"
--Forwarded Message
Content-Type: application/pem-signature
Version: 5
Originator-ID-Asymmetric: ...,09
Expires Apr, 1994 [Page 16]
draft MIME-PEM Interaction Jul 1993
MIC-Info: RSA-MD5,RSA,...
--Forwarded Message
Content-Type: application/quoted-mime-entity
Content-Type: message/RFC822
Date: Mon, 29 Mar 93 13:53:02 -0500
From: Ned Freed <ned@innosoft.com>
To: Greg Vaudreuil <gvaudre@IETF.CNRI.Reston.VA.US>
Subject: Minimal PEM Message
This is a signed message using MIME-PEM.
Greg V.
--Forwarded Message--
--Middle Boundary--
--Privacy Boundary--
The following privacy-enhanced body part illustrates the use
of encryption and the application/pem-encrypted content type.
Content-Type: multipart/headerset;
boundary="PEM Boundary"
--PEM Boundary
Content-Type: application/pem-keys
Version: 5
DEK-Info: DES-CBC,4C776432D61A9829
Originator-ID-Asymmetric: ...,09
Key-Info: RSA,...
--PEM Boundary
Content-Type: application/pem-encrypted
Content-Transfer-Encoding: base64
8R/EVhZy7OU=
--PEM Boundary--
Expires Apr, 1994 [Page 17]
draft MIME-PEM Interaction Jul 1993
If it was desired to produce a signed and encrypted body part,
the signature would be done first, producing:
Content-Type: multipart/headerset;
boundary="Sign Boundary"
--Sign Boundary
Content-Type: application/pem-signature
Version: 5
Originator-ID-Asymmetric: ...,09
MIC-Info: RSA-MD5,RSA,...
--Sign Boundary
Content-Type: application/quoted-mime-entity
Content-Type: message/RFC822
To: Ned Freed <ned@innosoft.com>
Subject: Strongly Protected Message
This will be signed and encrypted. Let the bad guys
do their worst!
Jim
--Sign Boundary--
and then it would be encrypted, producing:
Content-Type: multipart/headerset;
boundary="Enc Boundary"
--Enc Boundary
Content-Type: application/pem-keys
Version: 5
DEK-Info: DES-CBC,4C776432D61A9829
Originator-ID-Asymmetric: ...,09
Key-Info: RSA,...
--Enc Boundary
Expires Apr, 1994 [Page 18]
draft MIME-PEM Interaction Jul 1993
Content-Type: application/pem-encrypted
Content-Transfer-Encoding: base64
9S/FWjAz8P=V
--Enc Boundary--
where the encrypted contents, 9S/FWjAz8P=V, are the encryption
of the first multipart/headerset.
9. Observations
The use of the pre-submission and post-delivery algorithms to
combine PEM and MIME capabilities exhibit several properties:
(1) It allows privacy-enhancement of an arbitrary content,
not just an entire RFC 822 message.
(2) For a multipart or message content, it allows the user to
decide whether the structure of the content should
receive what sort of privacy-enhancement.
(3) It provides for messages containing several privacy
enhanced contents, thereby removing the requirement for
PEM software to be able to generate or interpret a single
content which intermixes both unenhanced and enhanced
components.
The use of a MIME-capable user agent makes complex nesting of
enhanced message body parts much easier. For example, the
user can separately sign and encrypt a message. This
motivates a complete separation of the confidentiality
security service from the authentication/message integrity
security service. That is, different keys could be used for
the different services and protected separately. In the
asymmetric case, this means an employee's company could be
given access to the (private) decryption key, granting the
company the ability to decrypt messages addressed to the
employee in emergencies, without also granting the company
the ability to sign messages as the employee.
Expires Apr, 1994 [Page 19]
draft MIME-PEM Interaction Jul 1993
The use of two private keys requires the ability to maintain
multiple certificates for each user.
10. Acknowledgements
David H. Crocker suggested the use of a multipart structure
for MIME-PEM interaction.
11. References
[1] D.H. Crocker, Standard for the Format of ARPA Internet
Text Messages, RFC 822, August, 1982.
[2] N. Borenstein, N. Freed, Multipurpose Internet Mail
Extensions, RFC 1341, June 1992.
[3] J. Linn, Privacy Enhancement for Internet Electronic
Mail -- Part I: Message Encryption and Authentication
Procedures, RFC 1421, DEC, February 1993.
[4] S. Kent, Privacy Enhancement for Internet Electronic
Mail -- Part II: Certificate-Based Key Management, RFC
1422, BBN, February 1993.
[5] D. Balenson, Privacy Enhancement for Internet Electronic
Mail -- Part III: Algorithms, Modes, and Identifiers, RFC
1423, TIS, February 1993.
[6] B. Kaliski, Privacy Enhancement for Internet Electronic
Mail -- Part IV: Key Certification and Related Services,
RFC 1424, RSA Laboratories, February 1993.
[7] R. Braden, Editor, Requirements for Internet Hosts --
Application and Support, RFC 1123, October 1989.
12. Author Addresses
Steve Crocker
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
email: crocker@tis.com
Expires Apr, 1994 [Page 20]
draft MIME-PEM Interaction Jul 1993
Ned Freed
Innosoft International, Inc.
250 West First Street, Suite 240
Claremont, CA 91711
USA
Tel: +1 909 624 7907
Fax: +1 909 621 5319
email: ned@innosoft.com
Jim Galvin
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
email: galvin@tis.com
Sandra Murphy
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
email: murphy@tis.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
Tel: +1 415 968 1052
Fax: +1 415 968 2510
email: mrose@dbc.mtview.ca.us
Expires Apr, 1994 [Page 21]